Systems and methods of improving the quality of voip communications

ABSTRACT

Methods of addressing problems in a voice over Internet protocol (VOIP) telephony system include collecting data on network events, analyzing the data, and taking corrective action when possible. If an IP telephony device is registering with the VOIP telephony system more frequently than necessary, which can indicate the IP telephony device is unnecessarily jumping between proxy services, the IP telephony device is instructed to re-initialize itself. If an IP telephony device sends two successive stay alive registration messages to a proxy server from different ports of a router, which can indicate that a router pinhole is closing between stay alive messages, then the IP telephony device is instructed to send stay alive registration messages more frequently. If data packet statistics indicate that an IP telephony device is experiencing a jitter problem, the IP telephony device is instructed to increase the size of a data buffer for incoming data packets.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/087,557 filed Apr. 15, 2011, which claims priority to U.S.Provisional Application No. 61/324,518, which was filed Apr. 15, 2010,the entire contents of each of which are hereby incorporated byreference.

BACKGROUND

1. Field of the Technology

The technology is related to systems and methods that monitor andanalyze network events occurring within a Voice over Internet Protocol(VOIP) system to detect conditions that could result in poor callquality. The technology is also related to methods of automaticallytaking corrective action to correct detected problems.

2. Background of the Technology

VOIP telephony systems are used to transmit voice communications over adata network using Internet Protocol digital data packets. VOIPtelephony systems can supplement and/or replace existing analogtelephone systems. In VOIP systems, analog voice signals are convertedinto digital data packets which traverse the data network, and the datapackets are then converted back into voice signals.

In order to conduct a VOIP telephone call, the calling party must havean IP telephony device which is capable of converting analog voicesignals into digital data packets and transmitting the data packets overthe Internet. The IP telephony device must also be capable of receivingdata packets from a third party and converting those data packets intoanalog voice signals which are played to the user.

IP telephony devices can take many different forms. An IP telephonecould resemble a normal analog telephone, but the IP telephone would becapable of sending and receiving a call in the form of digital datapackets. An IP telephony device could also be embodied in a computerwith a microphone and a speaker, where the computer is running softwarethat enables the computer to conduct IP based telephone calls. An IPtelephony device could also be a mobile telephony device capable ofcommunicating via either a cellular telephony network, or via wirelessdigital data communications. In the following description, reference ismade to IP telephony devices. The term “IP telephony device” is intendedto cover any physical device and any associated software which enable auser to conduct an IP based telephone call.

It is also possible for a user to interact with a VOIP telephony systemusing a normal analog telephone. In these instances, an interface deviceis provided between the data network and the analog telephone. Theinterface device converts analog telephone signals from the analogtelephone into digital data packets that traverse the data network.Also, the interface device converts incoming digital data packets intoanalog signals that can be used by the analog telephone. Thus, the term“IP telephony device” is also intended to encompass the combination ofan analog telephone and an interface device.

IP telephony devices are typically connected to the Internet, or to someother data network, through some type of router device. In one commonscenario, a residential customer will have a high speed broadbandInternet connection that runs into the customer's house and whichterminates at a router. The router, in turn, is connected to a localnetwork within the customer's house. The IP telephony device used toconduct VOIP telephone calls is then connected to the local network, ordirectly to the router itself. The router is used to provide a highspeed Internet connection to not only the IP telephony device, but alsoto computers, and possibly to an entertainment system such as a cabletelevision set top box. Thus, the IP telephony device must share accessto the Internet connection provided by the router.

Typically, only a single IP address is assigned to the router. Becausemultiple devices within the user's home or office share access to theInternet connection, it is necessary for the router to conduct some sortof network address translation so that all of the devices within thecustomer's home or office can share the single IP address assigned tothe router.

In addition, the router will also typically include some type offirewall software which is used to prevent unauthorized data packetsfrom entering the local network and being delivered to the devicesconnected to the local network. As will be explained in more detailbelow, the firewall and the network address translation systems used bythe router can make it difficult to establish and maintain a VOIPtelephone call to an IP telephony device connected to the router or thelocal network.

In order to conduct a high quality VOIP telephone call, both theoriginating IP telephony device and the destination IP telephony devicemust be able to transmit and receive a certain number of data packetseach second. If sufficient communications bandwidth is not available,the call quality will be degraded. Likewise, if data packets sentbetween the two IP telephony devices are lost in transit, or if the datapackets arrive too far out of sequence, the call quality is degraded.

Insufficient bandwidth problems can occur when an IP telephony device issharing access to a broadband Internet connection with other devices,and those other device consume too much of the available bandwidth.Depending on the circumstances, the other devices on the local networkcould substantially continuously consume too much of the availablebandwidth, or the other devices might only periodically consume too muchof the bandwidth.

For instance, if a cable set-top box in a customer's home is streaming amovie to a display screen, the streaming of the movie might continuouslyconsume so much of the available bandwidth that any VOIP calls sufferdegraded call quality. On the other hand, if a computer located in thecustomer's home only periodically downloads large files, the computerwould only periodically consume too much of the available bandwidth. Asa result, a VOIP call being conducted while the computer conducts adownload would only temporarily experience degraded call quality. Assoon as the file is fully downloaded to the computer, the call qualitywould return to normal.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flowchart showing steps of a method for detecting andcorrecting problems with a VOIP telephony system;

FIG. 2 illustrates steps of a method of registering an IP telephonydevice with a VOIP telephony system;

FIG. 3 illustrates steps of a method of detecting and correctingproblems with an IP telephony device connected to a VOIP telephonysystem

FIG. 4 illustrates steps of a method that can be used to adjust a timinginterval between stay alive messages sent from an IP telephony device;

FIG. 5 illustrates steps of another method that can be used to adjust atiming interval between stay alive messages sent from an IP telephonydevice;

FIG. 6A illustrates elements of a typical VOIP telephony system;

FIG. 6B illustrates the flow path of data communications which can occurbetween devices in a typical VOIP telephony system;

FIG. 7 is a block diagram illustrating elements of a quality monitoringsystem which can be used in a VOIP telephony system;

FIG. 8A illustrates packet loss which occurs over time during a VOIPtelephone call;

FIG. 8B illustrates packet loss which occurs over time during adifferent VOIP telephone call; and

FIG. 9 illustrates steps of a method of taking corrective action tocorrect a call quality problem in a VOIP telephony system.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In a typical VOIP telephony system, various system assets will all beconnected to the Internet. The system assets can include the IPtelephony devices used by customers to conduct VOIP telephone calls. Thesystem could also include various network servers which are used toregister the IP telephony devices maintained by the customers, and whichcan be used to implement telephone calls between those IP telephonydevices. A VOIP telephony system may further include quality monitoringdevices which are used to monitor the quality of telephone calls placedbetween individual pairs of the IP telephony devices maintained by thecustomers.

The disclosed systems and methods involve monitoring actions or datatraffic occurring within a VOIP telephony system to identify conditionsthat may result in degraded call quality or that may result in theunnecessary consumption of bandwidth by unnecessary signaling betweendevices. When such conditions are identified, and where it is possibleto take corrective action, one or more elements of the VOIP telephonysystem or an IP telephony device take corrective action to alleviate theproblem.

FIG. 1 illustrates a generalized method embodying the invention.Individual implementations of this method can take multiple differentforms. However, as illustrated in FIG. 1, the method includes a firststep S102 of collecting data on network events. This can includemonitoring communications which are passing back and forth between theIP telephony devices maintained by the customers. This step could alsoinclude monitoring various call quality measures such as data packetloss and jitter statistics. Further, this step could include collectingtrouble reports which are generated by the IP telephony devices andwhich are sent to a central registration authority. Still further, thisstep could include monitoring or reviewing information about occurrencesof an IP telephony device registering with the VOIP telephony system.

In step S104 the collected data is analyzed to determine if problems maybe occurring on the network. As will be explained more fully below, theanalysis step could take many different forms. In some instances, theanalysis might be a comparison of an actual measured value or an averageof measured values to some predetermined threshold value. In otherinstances, if a particular type of event has occurred, the fact that theevent has occurred may be indicative of an actual or potential problem.In still other instances, a variety of different forms or items of datacould be collected and analyzed together to determine if a problem hasoccurred or if one is likely to occur.

In step S106 the system determines whether it would be possible to takecorrective action to remedy an actual or potential problem. The methodalso includes step S108 where corrective actions are implemented in anattempt to correct the problem. As will be described more fully below,the step of determining whether to take corrective action and the stepof actually taking that corrective action can take on a wide variety ofdifferent forms depending on the type of trouble which has beenidentified in the analysis step.

An IP telephony device may share access to the Internet through arouter. As also mentioned above, the fact that such a router mustimplement network address translation procedures and the fact that therouter includes a firewall can lead to a variety of different problemswith connecting and maintaining IP telephone calls. To better understandthe problems which can occur, we will first describe a process whichoccurs when an IP telephony device registers with an IP telephony systemwith reference to FIG. 2.

When an IP telephony device is first powered on and connected to theInternet, the IP telephony device will utilize the Internet connectionto contact a server maintained by the IP telephony system. In step S202,the IP telephony device obtains profile information from the server. Theprofile information could include the IP telephony device's telephonenumber, various other configuration data items, and possibly a passwordor authorization code which the device can use to register with the IPtelephony system. The profile information can also include a listing ofproxy servers which the device is authorized to contact in order toconduct a registration process. The proxy server group would typicallyinclude multiple proxy servers which are located in differentgeographical locations.

In step S204, the IP telephony device selects one of the proxy serversprovided in the profile information and the IP telephony device sends aregistration request message to that proxy server. In step S206, theproxy server sends back a challenge message to the IP telephony deviceasking the IP telephony device to provide special identificationinformation which will allow the proxy server to authenticate the IPtelephony device as authorized to conduct communications on the IPtelephony system.

In step S208 when the IP telephony device receives the challenge messagefrom the proxy server, the IP telephony device creates a digitalsignature and the digital signature is sent back to the proxy serverwith a response to the challenge message. The digital signature createdby the IP telephony device could be generated using the password orauthentication code that the IP telephony device received as part of itsprofile information. The digital signature could also be based uponinformation sent in the challenge message from the proxy server. Variousother items of information could also be encoded into the digitalsignature to uniquely identify the IP telephony device and also toindicate that it is authorized to conduct communications on the IPtelephony system.

In step S210, the proxy server itself creates a digital signature usingthe same pieces of information discussed above. The proxy servercompares the digital signature received from the IP telephony device tothe digital signature that it created. In step S212, if the two digitalsignatures match, this would indicate that the IP telephony deviceshould be authorized to conduct communications through the IP telephonysystem. Accordingly, in step S212, the proxy server would send an OKmessage back to the IP telephony device indicating that the digitalsignatures have matched and that the IP telephony device is nowauthorized to begin communications.

As mentioned above, in many cases, an IP telephony device used toconduct an IP telephone call is sharing access to the Internet through arouter. The router itself provides certain firewall functions to preventunauthorized data communications from being passed from the Internet toindividual devices within a customer's home or office. One common way inwhich those firewall systems operate relates to the generation of a“pinhole.” The term “pinhole” refers to a time based mechanism forallowing certain data packets to be passed from the Internet back todevices on a customer's local network.

Basically, each time that a local device on the local network within thecustomer's home sends a data packet through the router to a destinationdevice on the Internet, the router will note the IP address of thedestination device, as reflected in the data packet, and the router willstart a timer. For a certain predetermined period of time after thatdata packet has been sent, the router will allow data packets from thedestination device to be sent back to the local device on the localnetwork in the customer's home. However, once this predetermined timeperiod has expired, the router will block the delivery of any additionaldata packets sent from the destination device. In many commonly usedcommercial routers, the predetermined time period is approximatelythirty seconds. The thirty second time window during which data packetscan be received by the local router is commonly called a “pinhole.”

In the context of a VOIP telephony system, it is necessary for a proxyserver or other system assets of the IP telephony system to be able tosend messages to the IP telephony device on the local network in thecustomer's home at all times so that when there is an incoming call, theIP telephony device can be connected to that call. Unfortunately, if theIP telephony device has not recently sent a data packet to the deviceattempting to connect an incoming call, any data packets sent from thedevice in an attempt to establish the incoming call are blocked by therouter.

To prevent this from occurring, most IP telephony devices are configuredso that they periodically send a “stay alive” message to the IPtelephony system. The period of time that elapses between those stayalive messages is carefully configured to be smaller than thepredetermined period of time that the router uses to cut off incomingdata communications. For instance, if a router's firewall system isdesigned to cut off incoming data communications after 30 seconds, thenthe IP telephony device will be configured to send a stay alive messageto the IP telephony system every 20-25 seconds to ensure that the IPtelephony system is always able to send a data packet back to the IPtelephony device when it is necessary to set up a new incoming telephonecall. Periodically sending the stay alive messages continuously re-setsthe router's timer for a pinhole so that the pinhole remains open.

Returning to a discussion of the method illustrated in FIG. 2, once theproxy server has sent an OK message in step S212 to indicate that the IPtelephony device is authorized to conduct communications over the IPtelephony system, the process moves on to step S214. In step S214, theIP telephony device sends a new registration request message after apredetermined period of time has elapsed. As explained above, thepredetermined period of time will be shorter than the period of time atwhich a router will close the pinhole and cut off incoming datacommunications from the proxy server.

The transmission of this new registration message causes the router atthe customer's home or office to reset the pinhole timer. The proxyserver, knowing that the IP telephony device has recently registered,treats the new registration request message from the IP telephony deviceas a “stay alive” message. In other words, when this new registrationrequest message is received from the IP telephony device, the proxysever will not force the IP telephony device to again go through thewhole registration process described above. Instead, if the IP telephonydevice has recently gone through the registration process, the proxysever will simply send back an OK message.

The initial registration of the IP telephony device will typicallyremain valid for only a predetermined period of time on the order ofless than one day. Once that predetermined registration time period haselapsed, the system will force the IP telephony device to re-registerwith the system—meaning once again going through the full registrationprocess to ensure that the IP telephony device is still a valid devicewhich is authorized to conduct communications on the IP telephonysystem.

Accordingly, in step S216 of the method illustrated in FIG. 2, when theproxy server receives a registration message from an IP telephony deviceafter the device has already been registered, the proxy server willcheck to determine how long it has been since the IP telephony deviceconducted its last full registration. If that full registration processwas relatively recent, and the registration time period has not expired,the method will proceed to step S218 and the proxy server sends an OKmessage back to the IP telephony device. The method will then loop backto step S214, and the IP telephony device waits for the predeterminedtime period (20-25 seconds) to elapse before sending a new registrationrequest (stay alive) message back to the proxy server. Steps S214, S216and S218 will continue to occur until the full registration time periodhas elapsed.

In some IP telephony systems, an IP telephony device will be able tomaintain a valid registration with the system for a period ofapproximately eight hours. At the end of the eight hour registrationtime period, it will be time for the IP telephony device to conduct anew full registration process. Accordingly, when the proxy serverdetermines in step S216 that the IP telephony device's registration timeperiod has expired, the method will loop back to step S206. The proxyserver sends a regular challenge message to the IP telephony devicerequesting that the IP telephony device conduct a full new registrationprocess. The method then proceeds through the registration steps asexplained above.

In one embodiment of the invention, if there are no problems with the IPtelephony system or with the IP telephony device, the IP telephonydevice will go through the full registration process once every eighthours, and the IP telephony device will continue to send stay alivemessages to the proxy server once every 20-25 seconds. However, thereare multiple different problems which can occur with the devicesthemselves or with the data communications. Any one of these problemscan result in blocked calls or the inability of an IP telephony deviceto receive an incoming telephone call.

In some instances, a software bug or other physical difficulties with anIP telephony device can cause the IP telephony device to send itsperiodic stay alive messages to a proxy server other than the one withwhich the IP telephony device originally registered. In other words, afirst stay alive message will be sent to a first proxy server with whichthe IP telephony device initially registered, and a second subsequentstay alive message will be sent to a second proxy server. When thesecond proxy server receives the stay alive message, the second proxyserver will not recognize the IP telephony device as having already beenregistered. As a result, the second proxy server sends back a challengemessage which requires the IP telephony device to conduct a new fullregistration process. The IP telephony device will go through theregistration process described above with the second proxy server, andthe IP telephony device will then send stay alive messages to the secondproxy server.

If IP telephony devices are only required to re-register with theirproxy server once every 8 hours, then one should only see that aparticular IP telephony device has registered with the system threetimes in every 24 hour period. If the registration records for aparticular IP telephony device show that the IP telephony device isregistering with the system more than three times in each 24 hourperiod, this means that the IP telephony device is jumping from oneproxy server to another before the normal eight hour registration timeperiod expires. Such a condition is indicative of a problem with thesoftware on the IP telephony device or a physical problem with the IPtelephony device.

Because the IP telephony device is still registering with at least oneproxy server on the system, it will still be possible for the device toreceive incoming telephone calls. However, the fact that the IPtelephony device is sending successive stay alive messages to differentproxy servers, and then jumping from one proxy server to another,indicates that there is likely a problem with the IP telephony deviceitself. And this problem may not be limited to just sending stay alivemessages to different proxy servers.

The IP telephony system can record each time that an IP telephony deviceregisters with the system. This could include maintaining a continuouslog of all registrations conducted by the IP telephony device, ormaintaining a record of all registrations that occurred for the IPtelephony device over a predetermined period of time, such as one day.The IP telephony system can then check these records to determine if anIP telephony device appears to be registering too often. When thisproblem is detected, the IP telephony system can instruct the IPtelephony device to re-initialize or reboot itself in an attempt tocorrect the problem. Often, a simple reboot of the IP telephony devicewill cure the problem.

The system can instruct the device to re-initialize or reboot itselfduring a point in time when it is highly unlikely that the customerwould desire to place or receive a telephone call. For instance, the IPtelephony system could instruct the IP telephony device to reboot itselfat 4:00 am local time. Once the IP telephony device has rebooted, itwill conduct the method illustrated in FIG. 2, where a normalregistration process is conducted, and the IP telephony device beginssending out periodic stay alive messages.

Another problem which can occur is reflected in the originating IPaddress of the stay alive messages sent from an IP telephony device. Ifan IP telephony device is sending its stay alive messages through arouter, the router will insert its assigned IP address into the datapackets before the stay alive messages are sent on to the proxy server.However, in some instances, successive stay alive messages sent from anIP telephony device will reflect different originating IP addresses.This can occur for a variety of different reasons.

For instance, if the router forwarding the stay alive messages for an IPtelephony device temporarily became disconnected from the Internet, whenthe router re-connects, it will be assigned a new IP address. Thus, thenext time that the router forwards a stay alive message from the IPtelephony device on to the proxy server, the stay alive message willindicate a different originating IP address than the one contained inthe last stay alive message sent from the IP telephony device.

To ensure that there are no problems, whenever a proxy server determinesthat successive stay alive messages received from an IP telephony devicehave come from different originating IP addresses, the proxy server willrequest that the IP telephony device conduct a full new registrationprocess. Alternatively, the proxy server may instruct the IP telephonydevice to re-initialize or reboot itself, which will also cause the IPtelephony device to conduct a full registration process.

Another problem that can occur relates to the time interval betweensuccessive stay alive messages sent from an IP telephony device. Asexplained above, a router will maintain a pinhole for a particular IPtelephony device for a certain predetermined period of time. If the IPtelephony device does not send a new stay alive message to its proxyserver within that predetermined period of time, the pinhole will beclosed. If the router closes the pinhole before the IP telephony devicesends out its next stay alive message, there will undesirably be acertain period of time when it is impossible for the proxy server of theIP telephony system to contact the IP telephony device.

In most commercially available routers, the pinhole will be kept openfor at least 30 seconds, and sometimes for periods as long as fiveminutes. Because thirty seconds is typically the shortest duration forpinholes, most IP telephony devices are configured to send out stayalive messages every 20 to 25 seconds, which ensures that the pinholeremains constantly open.

In some instances, however, a router might be configured to close apinhole after less than 30 seconds. To avoid situations where a routeris closing the pinhole before the IP telephony device can send out itsnext stay alive message, it is possible to adjust the frequency withwhich the stay alive messages are sent. But before this is done, it isnecessary to know that the problem exists in the first place.

Each of the stay alive messages sent by the IP telephony device willreflect the UDP port of the router to which the IP telephony device isconnected. If the router never closes the pinhole, successive stay alivemessages will always reflect the same UDP port. However, if a router isclosing the pinhole before the IP telephony device can send out its nextstay alive message, then the next time the IP telephony device sends astay alive message, the stay alive message will likely reflect adifferent UDP port. Thus, if successive stay alive messages received bythe proxy server reflect different UDP port numbers, this indicates thatpinhole is being closed between each stay alive message.

If the proxy server determines that the port number of successive stayalive messages has changed, the system can then signal the IP telephonydevice to increase the frequency with which the stay alive messages aresent. In other words, the time period that elapses between thetransmission of successive stay alive message is shortened. The IP-basedtelephony system will continue to instruct the IP telephony device toshorten the time period between stay alive messages until successivestay alive messages all reflect the same UDP port number. So long as thesystem notes that the stay alive messages are all coming from the sameport, this provides an indication that the stay alive messages are beingsent before the pinhole is closed.

FIG. 3 illustrates steps of a method which combine all of theabove-identified problem detection and corrective actions. A briefdescription of the overall process follows.

In step S302, a newly connected IP telephony device conducts a normalregistration process as has been described with reference to FIG. 2.Next, in step S303, a tuning process is conducted to adjust thefrequency with which the stay alive messages are sent from the IPtelephony device. This process will be discussed in more detail below.However, the purpose of the tuning step is to adjust the duration of thetime interval between successive stay alive messages to reduceunnecessary messaging traffic while still ensuring that the router nevercloses the pinhole.

Next, in step S304, the IP telephony device sends its first stay alivemessage after registration and tuning In step S306, the proxy serverdetermines if the predetermined registration time period for the IPtelephony device has expired. As noted above, it would be typical for aregistration time period to expire once every 8 hours. In step S306, ifthe proxy server determines that the registration time period hasexpired, the method returns to step S302 where the IP telephony deviceis required to conduct another full registration process. If thepredetermined registration time period has not yet expired, the methodcontinues to step S308.

In step S308, the proxy server determines if the current stay alivemessage for the IP telephony device has been sent from a different IPaddress than a previous stay alive message. As explained above, if thishas occurred, it may be indicative of a problem. Accordingly, if thishas occurred, the method returns to step S302, and the IP telephonydevice is required to conduct another full registration process. If thecurrent stay alive message has been received from the same IP address asthe previous stay alive message, the method continues to step S310.

In step S310, the proxy server checks to determine if the IP telephonydevice appears to be jumping proxy servers. As noted above, this can bedetermined by checking the number of times that the IP telephony devicehas registered with the IP telephony system over a predetermined periodof time. As mentioned above, if the IP telephony device is jumping proxyservers, this could be indicative of a software or device problem. Ifthis has occurred, the method proceeds to step S312 where the IPtelephony device is instructed to reboot itself The instruction can bean instruction to immediately reboot. In this case, the method proceedson to step S302 where the device conducts a new registration process.The instruction to reboot could also be an instruction to conduct thereboot process at some specified time in the future. In that case, themethod might simply proceed on to step S314. Also, if this check doesnot indicate that the device is jumping proxy servers, the methodproceeds to step S314.

In step S314, the proxy server checks to determine if the current stayalive message indicates the same UDP port of the router as the previousstay alive message. If the port number has changed since the previousstay alive message, this can indicate that the router is closing thepinhole between successive stay alive messages. Accordingly, if this hasoccurred, in step S316, the IP telephony device is instructed to performa message timing operation.

In one embodiment, the message timing operation will decrease the timeinterval between successive stay alive messages, as described below withreference to FIG. 4. In other embodiments, the message timing operationcan increase or decrease the time interval between stay alive messagesto improve message traffic overhead efficiency as described below withreference to FIG. 5.

The method then moves on to step S318. In alternate embodiments, afterthe time interval between successive stay alive messages has beenadjusted, the IP telephony device is instructed to conduct another fullregistration process. In step S314, if the current stay alive messageindicates the same port number as the preceding stay alive message, themethod moves on to step S318, where the proxy server sends an OK messageto the IP telephony device. The method then moves back to step S304,where the IP telephony device sends another stay alive message after ashort predetermined period of time has elapsed.

Although the method illustrated in FIG. 3 includes multiple differentchecks to determine if problems have occurred and multiple differentcorrective actions if a potential problem (i.e., a communication fault)has been noted, an individual method embodying the technology need notinclude all of these steps. One or more of these steps could be omitted.Further, additional checks could be performed and additional correctiveactions could be taken.

In step S316 of the method described above, a message timing operationis performed. If the system has noticed that there is a problem with thetiming interval between successive stay alive messages, and that arouter connected to the IP telephony device is closing the pinholebetween successive stay alive messages, one solution is to decrease thetime interval between successive stay alive messages. However, each stayalive message and the corresponding response from the associated proxyserver represent overhead messaging traffic that the system must bear tokeep the system operating properly. These messages do nothing to carryactual telephone calls. The messaging traffic associated with the stayalive messages and the replies from the proxy servers simply ensure thatthe IP telephony system is always able to reach the IP telephony device.

Because the stay alive messages and the replies from the proxy serversare only overhead, it is desirable to generate them as seldom aspossible and still keep the system operating properly. For this reason,when it becomes necessary to adjust the interval between successive stayalive messages, it is desirable to also ensure that the stay alivemessages are only sent as often as strictly necessary to ensure that therouter keeps the pinhole open. The method illustrated in FIG. 4 isdesigned to accomplish this purpose.

In step S402, the IP telephony system instructs the IP telephony deviceto decrease the interval between successive stay alive messages. But thesystem would only instruct that the interval be reduced by a very smallamount—perhaps one second or less. In step S404, the system waits toreceive at least two successive stay alive messages that have been sentwith the new timing interval.

In step S406, the system checks to determine if the same UDP port isreflected in both stay alive messages. If so, this indicates that thetiming interval has been adjusted to a small enough time period so thatthe router will no longer close the pinhole between successive stayalive messages. If not, the method loops back to step S402, and the IPtelephony device is again instructed to further reduce the timinginterval between successive stay alive messages by another small amount.This process continues until the system determines in step S406 thatsuccessive stay alive messages reflect the same UDP port, whichindicates that the problem has been solved.

A method as illustrated in FIG. 4 ensures that any problem with thepinhole closing is solved, and that the interval between successive stayalive messages is kept as long as possible. This minimizes the amount ofoverhead caused by these messages so far as is possible.

FIG. 5 illustrates steps of a method which can be used to adjust thetiming of the stay alive messages to potentially reduce the amount ofoverhead created by the stay alive messages and the corresponding OKmessages sent from the proxy servers back to the IP telephony devices.In this method, the timing interval between successive stay alivemessages is adjusted to become longer in those instances where it ispossible. A method as illustrated in FIG. 5 could be conducted each timethat the IP telephony device conducts a full registration process with aproxy server. Thus, a method as illustrated in FIG. 5 could be thetuning step which appears as step S303 of the method illustrated in FIG.3.

The method starts in step S502, where the proxy server receives at leasttwo successive stay alive messages from an IP telephony device. In stepS504, the system checks to determine if the same port number isreflected in both stay alive messages. If so, this would mean that thetime interval between successive stay alive messages is sufficientlylong to prevent the router from closing the pinhole. However, at thispoint the system would not know whether the IP telephony device issending successive stay alive messages just fast enough to prevent thepinhole from closing, or if the IP telephony device is sending stayalive messages far more often than is necessary to keep the pinholeopen.

Assuming the port numbers were the same during the check performed instep S504, the method proceeds to step S506, where the system instructsthe IP telephony device to lengthen the time period between successivestay alive messages.

In step S508, the system waits to receive at least two successive stayalive messages under the new longer timing interval. In step S510 thesystem again checks to determine if the port number for successive stayalive messages is the same. If so, this would indicate that even thelengthened time period between successive stay alive messages wassufficient to keep the pinhole open. If that is the case, the methodloops back to step S506, where the system again instructs the IPtelephony device to lengthen the time period between successive stayalive messages. This process would continue until in step S510 it isdetermined that the port numbers in successive stay alive messages isdifferent. This would indicate that the timing interval being used bythe IP telephony device has finally become so long that the stay alivemessages are not being sent quickly enough to keep the pinhole alive. Atthis point, the method moves on to step S512.

In step S512, the system instructs the IP telephony device to decreasethe interval between successive stay alive messages. In step S514, thesystem waits to receive at least two successive stay alive messages thathave been sent with the new timing interval.

In step S516, the system checks to determine if the same UDP port isreflected in both stay alive messages. If so, this would indicate thatthe timing interval has been adjusted to a small enough time period sothat the router will no longer close the pinhole between successive stayalive messages. If not, the method loops back to step S512, and the IPtelephony device is again instructed to further reduce the timinginterval between successive stay alive messages by another small amount.This process continues until the system determines in step S516 thatsuccessive stay alive messages reflect the same UDP port, whichindicates that the timing interval between successive stay alivemessages is short enough to prevent the pinhole from closing.

With a method as illustrated in FIG. 5, each individual IP telephonydevice can adjust the timing interval between successive stay alivemessages to suit the configuration of the router to which it isattached. The interval will be adjusted to be as long as possible, giventhe characteristics of the router to which it is attached. And becausethe interval is made as long as possible, unnecessary signaling betweenthe IP telephony device and its proxy server will be reduced, loweringthe overhead messaging traffic.

The amount by which the time interval is lengthened in step S506, andthe amount by which the interval is shortened in step S512 need not bethe same. For instance, the time interval could be lengthened by 5seconds in step S506, whereas the interval could be shortened by 1second in step S512, or vice versa.

As explained above, an IP telephony system could include various ways ofmonitoring the call quality of calls placed between individual IPtelephony devices. Typical call quality monitoring would includedetecting or calculating packet loss and jitter statistics forindividual telephone calls. In some instances, those detected orcalculated statistics could be used to take corrective action to improvea user's overall experience. One such method will be discussed withreference to FIGS. 6A-8B.

FIG. 6A illustrates elements of an IP telephony system. As shown in FIG.6A, a first IP telephony device 602 and a second IP telephony device 604would both be connected to the Internet. In addition, a media relay 606could also be connected to the Internet. A call quality monitoringsystem 608 could be connected to the Internet, and also possibly to themedia relay 606.

The data communications paths which exist between the devicesillustrated in FIG. 6A are better illustrated in FIG. 6B. As shown inFIG. 6B, when a telephone call has been established between the first IPtelephony device 602 and the second IP telephony device 604, the datapackets which carry audio (i.e., voice) information specific to thattelephone call can pass through a media relay 606. Data packets sentfrom the first IP telephony device 602 would pass along a first outboundpath 605 to the media relay 606. The media relay 606 would then sendthose data packets along a second inbound path 607 between the mediarelay 606 and the second IP telephony device 604. Data packets sent fromthe second IP telephony device 604 to the media relay 606 would passalong a second outbound path 609. Those data packets would then becommunicated from the media relay 606 to the first IP telephony device602 along a first inbound path 603.

Because a quality monitoring system 608 is connected to the media relay606, the quality monitoring system is able to monitor the data packetcommunications on both the first and second inbound paths and the firstand second outbound paths, all of which pass through the media relay606. As a result, it is possible to obtain data packet loss and jitterstatistics for each of these four transmission legs.

The quality monitoring system 608 is illustrated in greater detail inFIG. 7. As shown therein, the quality monitoring system can include ajitter detector 610, a packet loss detector 612, and an IP telephonydevice reporting and collection unit 614. A quality metrics calculationunit 616 could calculate averages of any of these statistics or thequality metrics calculation unit 616 could generate call quality metricswhich are based upon multiple ones of the detected values.

The IP telephony device reporting and collection unit 614 can collectinformation from the IP telephony devices themselves. For instance, theIP telephony devices could also detect and report packet loss and jitterstatistics. The IP telephony devices might also report when they areforced to discard a data packet because it has been received so far outof order that it cannot be used in an audio stream.

Although the above discussion focused on jitter and packet loss, avariety of other data packet communication statistics could also bedetected and calculated.

IP telephony devices use an encoding algorithm to convert an audiostream into digital data packets, and to convert the data in digitaldata packets back into an audio stream. Different encoding algorithmsoperate in different fashions. Some encoding algorithms utilize datacompression techniques to send an audio stream in as few data packets aspossible. When an encoding algorithm uses data compression techniques,the audio quality is typically somewhat degraded. However, the use ofdata compression techniques makes it possible to transmit a particularaudio stream using less bandwidth than an encoding algorithm that doesnot use data compression techniques.

In instances where there is insufficient bandwidth for an IP telephonydevice to conduct a high quality voice call, it may be possible toconduct the call with slightly degraded audio quality if the IPtelephony device employs an encoding algorithm using data compressiontechniques. Although the audio quality may suffer slightly as a resultof the data compression, it is usually the case that the deteriorationin the audio quality caused by the data compression will be less thanthe deterioration which occurs if no compression is used and datapackets are simply being lost.

In those situations where the available bandwidth is continuouslyinsufficient for an IP telephony device to conduct a high quality callwithout data compression, it would be desirable to cause the IPtelephony device to begin using an encoding algorithm with compressiontechniques. However, in those instances where the amount of availablebandwidth is almost always sufficient to conduct a high quality callwithout data compression, but where it sporadically becomesinsufficient, it may make sense to continue conducting calls with anencoding algorithm that does not use data compression techniques. Thisensures that almost all of the time, the calls are conducted at thehighest possible quality. In addition, where sporadic bandwidth problemsoccur, even if the IP telephony device converted to the use of anencoding algorithm with data compression technology, the use of thecompression technology might not solve the problem. In other words,switching the IP telephony device over to an encoding algorithm thatuses data compression techniques may not be of any help in solving aproblem which is caused by another device periodically using almost allof the available bandwidth.

In order to distinguish between these two different situations, one canlook at the packet loss and/or jitter statistics for a particular IPtelephony device. FIGS. 8A and 8B illustrate the packet loss whichoccurs in these two different situations during calls conducted by an IPtelephony device.

FIG. 8A illustrates a situation where another device which is sharingaccess to a broadband Internet connection sporadically uses a portion ofthe available bandwidth. As illustrated in FIG. 8A, the packet lossincreases sharply and then decreases again as the other device consumesand then releases a percentage of the available bandwidth. Accordingly,there are only three distinct points in time 802, 804, 806 where thepacket loss is large enough to impact voice communications through theIP telephony device.

FIG. 8B illustrates a different situation where the packet loss isrelatively constant over time. This indicates that the availablebandwidth is simply insufficient for the IP telephony device to conducta high quality voice telephone call without the use of compressiontechniques.

The quality monitoring system 608 would monitor the packet loss orjitter statistics for telephone calls in an attempt to distinguishbetween these two different situations. If it appears that the situationis as illustrated in FIG. 8B, where the available bandwidth is simplyinsufficient, then the quality monitoring system could instruct the IPtelephony device to begin to use data compression. As explained above,this might degrade the call quality slightly, but the degradation in thecall quality will still be less than the degradation which occurs due tothe packet loss when no data compression is being used.

Although FIGS. 8A and 8B illustrate packet loss which occurs during atelephone call, jitter statistics could be used in place of packet loss.In alternate embodiments, both packet loss and jitter statistics couldbe used together to determine when it may be desirable to cause an IPtelephony device to switch to an encoding algorithm that uses datacompression techniques. Moreover, in alternate embodiments, statisticson data communications other than packet loss and jitter could be used.

A method of monitoring data packet communication statistics and takingcorrective action is illustrated in FIG. 9. As shown therein, in a firststep S902, the data packet statistics for data packets communicated toand/or from an IP telephony device are monitored over a period of time.In step S904, those data packet communication statistics are analyzed todetermine certain trends. In step S906, if the analysis indicates thatthe bandwidth available to the IP telephony device is simplyinsufficient on a relatively continuous basis, the method proceeds tostep S908. In step S908, the IP telephony device is instructed to beginusing an encoding algorithm with data compression techniques. The methodwould then end. On the other hand, if in step S906 it was determinedthat the available bandwidth is sufficient, or that it only becomesinsufficient on an intermittent or sporadic basis, the method wouldsimply end.

Jitter statistics provide a measure of how far out of sequence datapackets are being received at a destination device. When a first IPtelephony device converts an audio stream into data packets, the datapackets are provided with sequence numbers. The numbered data packetsare then sent to a second IP telephony device. Because of the way datapackets traverse the Internet, it is common for the data packets toarrive at the second IP telephony device out of sequence. The second IPtelephony device uses the sequence numbers to place the data packetsback into the proper order, and then the data within the packets is usedto re-create the audio stream.

Most IP telephony devices maintain a buffer for incoming data packets.The use of a buffer allows a receiving IP telephony device time to placethe incoming data packets back into the proper order before the datapackets are used to re-create the audio stream. However, if delivery ofa data packet is considerably delayed, it may arrive too late to beplaced in the proper sequence with the other data packets. In theseinstances, the late data packet is typically discarded. When the datapackets are used to re-create the audio stream, because a data packet ismissing, the audio stream will not be perfect. The worse the jitterproblem becomes, the more the audio quality will be degraded.

As noted above, one expects that some data packets will arrive out ofsequence, and the buffer for the incoming data packets is designed tohelp overcome this problem. Audio quality is only impacted if the jitterproblem has become bad enough that data packets are being received solate that they cannot be inserted back into the stream at the properlocation. One way of compensating for a bad jitter problem is toincrease the size of the buffer. If the buffer is larger, it gives thereceiving IP telephony device more time to get the data packetsreassembled into the proper order before the data packets are used tore-create the audio stream.

Of course, maintaining the buffer consumes memory resources. The largerthe buffer becomes, the more memory is required. Also, one real worldconsequence of maintaining the buffer is that re-creation of the audiostream is delayed. If the buffer becomes larger, the delay becomeslarger. If the buffer becomes too large, then the delay will becomenoticeable to the two people conducting a telephone call.

One way of helping to maintain the quality of a VOIP telephone call isto monitor the jitter statistics for data packets passing between two IPtelephony devices. If the jitter statistics indicate that the datapackets are arriving at an IP telephony device so far out of sequencethat call quality is suffering, then the system can instruct the IPtelephony device to increase the size of the buffer to try to helpovercome the problem. The degree to which the buffer is increased can bebased upon how bad the jitter problem appears to be, as reflected in thejitter statistics.

While the invention has been described in connection with what ispresently considered to be the most practical and preferred embodiments,it is to be understood that the invention is not to be limited to thedisclosed embodiments, but on the contrary, is intended to cover variousmodifications and equivalent arrangements included within the spirit andscope of the appended claims.

1. A method of taking a corrective action by an internet protocol (IP)telephony device related to its registration to an IP telephony system,comprising: in response to a determination that two successive stayalive registration requests sent from the IP telephony device originatefrom different IP addresses, receiving an instruction to re-initializeitself; re-initializing upon receipt of the instruction; and conductinga new registration process with the IP telephony system therebyregistering a current IP address with the IP telephony system.
 2. Themethod of claim 1, wherein the instruction is received upon determiningthat the IP telephony device is conducting a full registration processwith one or more proxy servers of the IP telephony system morefrequently than necessary.
 3. The method of claim 1, wherein theinstruction is received by the IP telephony device upon determining thattwo successive stay alive registration requests sent from the IPtelephony device originate from different ports of a router.
 4. Themethod of claim 3, further comprising receiving an instruction to sendstay alive registration requests from the IP telephony device morefrequently when two successive stay alive registration requests sentfrom the IP telephony device originate from different ports of a router.5. A method of taking a corrective action by an IP telephony device tocorrect a potential problem, comprising: in response to a determinationthat a measure of data packet communication errors experienced by the IPtelephony device exceed a threshold value for more than a predeterminedperiod of time, receiving an instruction to switch itself from using afirst encoding algorithm to using a second encoding algorithm whichutilizes greater data compression than the first encoding algorithm; andswitching from using the first encoding algorithm to using the secondencoding algorithm upon receiving the instruction.
 6. The method ofclaim 5, wherein the measure of data packet communication errorscomprises a measure of data packet jitter.
 7. The method of claim 5,wherein the measure of data packet communication errors comprises ameasure of data packet loss.
 8. The method of claim 5, wherein themeasure of data packet communication errors comprises a measure of datapackets that are out of sequence.
 9. The method of claim 5, wherein thesecond encoding algorithm causes the data communications to use lessbandwidth using the second encoding algorithm than the datacommunications using the first encoding algorithm.
 10. The method ofclaim 5, wherein audio data in the data packet communication using thesecond encoding algorithm is of a lower quality than audio data in thedata packet communication using the first encoding algorithm.
 11. Themethod of claim 5, wherein video data in the data packet communicationusing the second encoding algorithm is of a lower quality than videodata in the data packet communication using the first encodingalgorithm.
 12. The method of claim 5, wherein the IP telephony device isinstructed to switch from using the first encoding algorithm to usingthe second encoding algorithm when an average value of the measured datapacket communication errors over the period of time is below a specifiedthreshold.
 13. The method of claim 5, wherein the IP telephony device isinstructed to switch from using the first encoding algorithm to usingthe second encoding algorithm when the measured data packetcommunication errors at one or more points in time over the period oftime fall below a specified threshold.
 14. The method of claim 5,wherein the IP telephony device is configured to receive data packets,in a buffer memory of the IP telephony device, from another device, andeach data packet having a sequence number assigned to the data packetthereby allowing the IP telephony device to put each data packet into aproper sequence of data packets.
 15. The method of claim 14, wherein theIP telephony device expands a size of the buffer memory when a level ofdata packet jitter and/or a level of data packet loss in the receiveddata packets exceeds a threshold value.
 16. The method of claim 15,wherein the size of the buffer corresponds to the level of data packetjitter and/or the level of data packet loss in the received datapackets.
 17. A method of adjusting a frequency in which an IP telephonydevice sends stay alive registration messages to a proxy server of avoice over internet protocol (VOIP) telephony system to keep the IPtelephony device within a pinhole communication window of the proxyserver, comprising: receiving an instruction to increase a delay betweenperiodic transmission of stay alive registration messages sent from theIP telephony device based on an identification of which port of a routerthe IP telephony device is associated; increasing the delay betweenperiod transmission of stay alive registration messages upon receivingthe instruction to increase the delay; upon determining that twosuccessive stay alive registration messages sent from the IP telephonydevice originate from different ports of a router, receiving aninstruction to decrease a delay between the periodic transmission ofstay alive registration messages sent from the IP telephony device; anddecreasing the delay between periodic transmission of stay aliveregistration messages upon receiving the instruction to decrease thedelay.
 18. The method of claim 17, wherein the amount by which the IPtelephony device is instructed to increase the delay is greater than theamount by which the IP telephony device is instructed to decrease thedelay.
 19. A method of stopping an IP telephony device from jumpingbetween proxy servers of a VOIP telephony system, comprising: upondetermining that an IP telephony device is conducting a fullregistration process with one or more proxy servers of a VOIP telephonysystem more frequently than required by the VOIP telephony system, basedon a number of registration attempts the IP telephony device hasconducted within a specified period of time, receiving an instruction totake a corrective action when the number of registration attemptsconducted within the specified period of time exceeds a threshold value;and taking the corrective action upon receiving the instruction.
 20. Themethod of claim 19, wherein the IP telephony device is instructed tore-initialize itself.